Skip to main content

Indicator Match Rules

STEP 1: Navigate to Rule Management​

  1. Expand the left-hand menu and navigate to the Security app

  2. Click on the Rules button under the Security app

  3. Click the Detection rules (SIEM) option from the Rules section

STEP 2: Import "Value List(s)"​

note

Indicator Match rules require the additional step of importing a Value List (a list of IOCs) before creating the rule. A Value List is just simple file containing strings, IPs, or network CIDRs (1 item per line).

  1. Click on the Manage value lists button in the top-right corner of the Rules page

  2. Upload a simple indicator list (1 item per line) text file of keywords (like URLs, hashes, filenames, or any other string), IP addresses, or IP ranges.

    NOTE: Each indicator list text file must contain the same types of indicators (for example: no mixing URLs with Hashes, etc.)

  3. Repeat these upload steps for each type of indicator you have

STEP 3: Create the Rule​

  1. Click on the +Create new rule button in the top-right corner of the Rules page

  2. Select the Indicator Match Rule type

(1) Define Rule​

  1. Source: Leave default index patterns as-is or select the specific data source(s) that the query will be ran against to make the rule more efficient.

  2. Custom query: Leave the default *:* query, or input a query that will filter for the specific logs that you want to alert on.

  3. Indicator index patterns: LEAVE THIS SET TO THE DEFAULT .items-default*

  4. Indicator index query: Set this to list_id:"<LIST_FILENAME>" - to specify that referenced value list will be file you imported (replacing <LIST_FILENAME> with the actual filename)

    note

    The default Indicator index query (@timestamp >= "now-30d/d") tells the rule to look at all value lists that were uploaded within the last 30 days – useful for aging out old IOC lists. Setting list_id explicitly targets the specific file you uploaded regardless of age.

  5. Indicator mapping: Match the Field that you want to search against with the Indicator index field (keyword, ip, or ip_range) depending on the type of indicator list uploaded.

    tip

    The following table lists the most common indicator types and the fields they are best mapped to for detection.

    IOC TypeFieldDescription
    IP Addressrelated.ip (ip/ip_range)IP addresses observed in network connections, DNS requests, or anywhere else
    Hashrelated.hash (keyword)Any type of file hash observed anywhere (from log sources that already have a hash generated)
    Hostname/FQDNrelated.hosts (keyword)Any hostname or FQDN observed in host logs, network connections, or DNS requests
    Emailrelated.email (keyword)Any email address
    Filenamerelated.file.name (keyword)A file name, such as example.png
    Filepathrelated.file.path (keyword)A full file path, such as /home/alice/example.png
    Usernamerelated.user (keyword)A username observed in any username type field
    Registry*registry.key (keyword)A registry key path (without the hive or value name)*, such as SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\winword.exe
    Registry*registry.path (keyword)A full registry path (including the value name)* in the format <HIVE>\<PATH_TO_KEY>\<VALUE_NAME>, such as HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\winword.exe\Debugger
    Registry*registry.data.strings (keyword)The exact content of any REG_SZ, REG_EXPAND_SZ, or REG_MULTI_SZ registry key
    URLurl.original (keyword)A full URL (including the FQDN, URI, and parameters), such as https://www.elastic.co:443/search?q=elasticsearch#top
    URIurl.path (keyword)Any URI, such as /search

  6. Optional - To test the rule logic, use the Rule Preview feature at the top of the page.

    NOTE: This requires that there are recent logs with data that will match your indicators

(2) About Rule​

note

When naming the rule, be descriptive about what is generating the rule (data source) without being too verbose - long rule names get truncated when alerts trigger.

  • Example: [262COS][IOC] Known-bad IP Observed

Fill each of the following fields:

  1. Name: A short descriptive title for the rule

  2. Description: Be verbose, as this is the first thing an analyst investigating the alert will look at to understand why the event is worth investigating

  3. Default severity: Set based on your assessment of the activity that the rule is trying to detect:

    ValueDescription
    LowMost likely to be a false positive or benign activity. Has minimal impact if it is a true positive
    MediumLikely to be benign activity, but can have some impact if it is a true positive
    HighUnusual occurance that may be benign, but still requires urgent attention when the alert is fired
    CriticalRare occurance that is almost always malicious and requires immediate attention whenever the alert is fired

  4. Tag: Add tags based on the 262COS rule tagging schema, heavily following the Sigma rule tagging specification:

    • Always add the 262COS tag at a minimum to identify the organization that created the rule

(2) About Rule - Advanced Settings​

Expand the Advanced Settings tab of the About Rule section and fill in each of the following applicable fields:

  1. Author: Add the name of each individual that contributed to the creation of the rule

  2. Timestamp override: Set to the event.ingested field so that rules will be queried against the time data was ingested and not when it occurred - this ensures that retroactively ingested data is also queried for alerting

(3) Schedule Rule​

  1. Runs every: The default of 5m is fine.

  2. Additional look-back time: The default of 1m is fine.

(4) Rule Actions​

No configuration required. Click Create & enable rule to save and run the rule.

Continue to the Rule Finalization section for tagging, exception lists, and enabling.